Jan 95 Viewpoint
Volume Number: 11
Issue Number: 1
Column Tag: The Editor’s Page
The Editor’s Page [Missing image]
By Scott T Boyd, Editor
Twice As Much Booger Glue In This Issue
As you’ve no doubt already noticed, this issue contains both an OpenDoc and an OLE CD.
That takes twice as much glue as we used in our August issue, which had just one CD.
This continues our efforts to keep you abreast of developing technologies. We’ve
thought about taking sides in this technology battle, but we’re not going to. First, we
believe that you can decide which, if either, technology best suits your needs. Second,
we don’t believe that it’s an either/or choice. Finally, both technologies have the
backing of companies with the resources to assure their success. We believe that both
OLE and OpenDoc will endure in the marketplace. Enjoy the CDs, and please let us hear
from you about your experiences.
EvenBetterBusError Caveat
Some of you have reported some interesting experiences with EvenBetterBusError
(EBBE) and PowerBooks. This is a well-understood phenomenon, and I should have
mentioned it previously. The short of it is this - EBBE and PowerBooks may not get
along. The long of it is this - PowerBooks have the ability to “sleep” the processor to
save battery. Also known as power cycling or rest mode, the Power Manager shuts off
the CPU for periods of inactivity, waking it up quickly when it sees signs of activity
(e.g. mouse movement, keystrokes, and such). Without power, the CPU loses its state,
so PowerBooks have code to store the CPU state on the stack. That’s fine, but how does
it find the stack when power is reapplied to the CPU? The processor expects to find the
SP and the PC at 0 and 4, respectively, so the Power Mgr writes those values there
before shutting off the CPU.
Now, given that EBBE was written prior to the release of the first PowerBooks,
and since it was written one floor up and about 100 feet away from where the
PowerBook software was written, you might expect that PowerBooks would know about
EBBE, and would save and restore the 8 bytes at zero around each sleep cycle, or even
just the 4 bytes at zero. Well, sorry to say, but the PowerBook team hadn’t heard of it
(I still vividly remember, “What’s EvenBetterBusError?”), so EBBE winds up
reporting “Write to NIL” a lot on PowerBooks. (Quick reminder: that’s because EBBE
watches the 32-bit value at 0 with a VBL task to see whether 0 has been changed from
the value $50FF8001 that EBBE put there in the first place).
The ROMs were nearly final by the time we realized we had a problem, and it was
only with a debugging tool, so they didn’t fix it. We considered a patch, but rejected it
when it became clear that a patch could disturb the very carefully-timed wake up code
and cause dropped incoming AppleTalk packets.
Bad news, right? Not as bad as it could be. You can turn off resting on
PowerBooks. It chews up batteries, but lets you test your code, and that can often be
done while plugged in.
It does raise a question, though - what kind of behavior does NIL-non-savvy
software exhibit when it gets the value of the rest-time stack pointer out of location
zero each time it dereferences NIL?
Strange Bedfellows
Who would have ever thought that Apple would willingly team up with IBM to sell
machines? There was a time when many thought that droves of employees would walk
right out the door should such a thing happen. But the Intel/Microsoft WinTel
domination serves as a powerful motivator. It was enough to convince IBM, Apple, and
Motorola to team up to build the PowerPC chip family, and now they’ve taken it one
step further and agreed to design a family of PowerPC machines that they’ll build, sell,
and run their operating systems on.
While the announcement covered hardware, almost nothing was said about
software. IBM reportedly wants to reassure their OS/2 user base that they are solidly
behind OS/2. Motorola seems to believe in Windows/NT. Apple continues to ride the
Macintosh wave. All of these existing allegiances notwithstanding, keep your ears open
for possible collaboration on the operating system front. With Apple’s plans to license
Mac OS, the only licensee we don’t expect to see is Microsoft.
Unclear On The Concept - Next Topic
When you ship software to customers, do you ever intentionally put them at risk?
Sounds silly, doesn’t it? Yet, that’s what at least two major software vendors have
done recently by shipping software that relies on undocumented and unsupported
features of Apple’s system software.
Apple’s programming interfaces don’t cover all the ground that Macintosh
programmers need to cover. Most of the time programmers compensate by writing
new code or reusing code from past projects, sample code, or a third-party source
library.
Sometimes a programmer will say, “Hey, you know, Apple must have something
like this in the system somewhere that they just haven’t documented. I’ll go figure out
how they do it.”
Such a thing happened during the development of System 7.0. Apple determined
that resource compression would make it possible to fit enough of 7.0 onto the Install 1
disk to be able to boot from the floppy. That’s pretty important to be able to do, so a
few engineers sat down and solved Apple’s problem by building a mechanism to
transparently decompress resources as they were loaded from disk. This mechanism
became known as the dcmp mechanism because of the new resources of type dcmp
which did the bulk of the work.
Inquisitive developers with similar needs (to squeeze lots of stuff into a little
space), noticed what Apple was up to. One of these dropped me a note after figuring out
how it all worked. He had even built his own decompressor to try his hand at beating
Apple on size and speed.
We talked, and I pointed out that the workings of the mechanism were not public,
nor supported. That’s because we (Apple) had done only enough testing to ensure that
it worked for the things that we were using it for. We hadn’t done the testing that any
public API necessarily goes through before publishing the interface. There wasn’t
time, there wasn’t money, and we weren’t even sure that we liked the mechanism well
enough to keep it beyond 7.0.
This developer decided, after mulling it over for a couple of days, that it was too
risky to use dcmps in his software. If Apple changed things, his customers would be
the ones with the problem - Apple might need to change it in the future, and it didn’t
make sense to put technological handcuffs on Apple just for this. Besides, with a little
thought, he had come up with a completely different mechanism, one which would work
fine no matter what Apple chose to do for compressed resources.
Two years ago, while I was still on the system software team at Apple, this
magazine ran an article by Justin Gray entitled Resource Compression - What it is,
how it works, and how to use it in your own software. The article was based on his
experiences using dcmps in some of his software. I called the Editor, and we had a
little “talk”. He got an earful, and learned that publishing unpublished Apple
internals was, shall we say, problematic. Neil says that his ears are still ringing
from that “talk”. (Little did I know where that conversation might lead - I learned
that I have to be careful what I complain about!)
It’s one thing to learn about how the Macintosh works. It’s quite another to
expose customers to the risk that their software may crash when they upgrade systems
simply because someone chose to use an unsupported internal mechanism when others
were readily available. At the start of this tirade, I mentioned two companies which
had recently shipped dcmp-dependent products. I spoke with one of them before they
shipped. Here’s a message to them: “Shame on you! You had alternatives that were
well-tested and immediately available, yet you chose not to use them. Will your
customers understand when they crash?”
If anyone is looking for resource compression that works without relying on
unpublished and unsupported code, e-mail me at editorial@xplain.com. If you have
such a product available, let me know, and I’ll add you to the list of resource
compression vendors that I send to those who ask.
Virtual Corporation Enabler
IRC stands for Internet Relay Chat. If you’ve ever participated in an online group
discussion, you’ll have a pretty good idea of the nature of irc. It runs on many servers
on the Internet and maintains the illusion that each server participates in all of the
many discussions. Tonight, for example, my irc server said, “There are 2876 users
and 1931 invisible on 111 servers, 77 :operator(s) online, 1529 :channels formed, I
have 139 clients and 1 servers.” I use Homer (available on your favorite info-mac
mirror site) to join in with the few thousand folks online.
So you can go chat. Big deal, right? It can be if you’re one of the growing breed
of work-at-home members of virtual corporations. Having my home office on the
Internet lets me carry on conversations with coworkers in any of the virtual
companies I’m a part of. It cuts phone costs, and is more interactive than e-mail. IRC
also allows direct file transfers.
A few of us on a recent MacHack planning conference call used irc take
one-on-one conversations off-line so we wouldn’t disrupt the meeting. It was also a
great place to crack jokes.
It’s possible for others to listen in on your chats, so be forewarned. Much of the
necessary communication between virtual coworkers runs towards the mundane, so the
tool can still offer quite a bit of utility. If you’re already on the net, it’s a cheap and
useful addition to your suite of net tools.
Food For Thought
Apple now has an infomercial. Microsoft is showing feel-good commercials. Neither
shows an 800 number for taking orders.